1. Field of the Invention
The present invention relates to electronic system level (ESL) tools for the design of electronic systems.
2. Related Art
A conventional electronic system level (ESL) tool is typically tailored, e.g., hard coded, to meet the requirements of its clients. This makes it difficult to extend the capabilities of the tool in order to support new clients and/or client requirements if such requirements were not designed for during the initial design of the tool. Unfortunately, one or more new infrastructures generally are required to be created to accommodate such new client requirements. As an undesirable consequence of creating such new infrastructures, frequently two or more language infrastructures must be created to handle a variety of clients. Such multiple language infrastructures typically duplicate many types and functions. Thus, much of the effort expended in creating such additional language infrastructures is deleteriously duplicative and wasteful.
A conventional art approach is shown in FIG. 1 (conventional art). The language infrastructures provide common operations such as parsing, managing an intermediate representation, evaluation, etc. Typically, there is a type system sub module to handle the types and functions supported by the tool.
Each language infrastructure is tailored to meet the requirements of its clients. Thus, it is difficult to support new flows with an existing language infrastructure if such a flow was not accommodated during the design of the language infrastructure. Consequently, a new language infrastructure must be created to support such new flows. Hence, as the tool evolves and new flows are added, often a multiplicity of language infrastructures are created to support such flows.
A language infrastructure designed to support C code generation is used as an example. This client needs to generate appropriate code for the user models. While the processing for standard C++ constructs is straightforward, the client would generally need support from the infrastructure to handle the types and functions. As the client processes an expression, depending on the type of operands used, it will find out from the language infrastructure the optimum code to be generated. The language infrastructure will maintain the necessary information about the types to be able to provide this support. If this tool is extended to support a hardware design language (HDL) generation flow as well, it may require very different information to be kept about the types, and it may not be possible to extend the previous language infrastructure in order to provide efficient support to both flows. As a result, the only resort under the conventional art is to create a new, separate language infrastructure for the new flow.
Under the conventional art, a language infrastructure does not scale well as the number of new flows increases, and a new language infrastructure is generally required for such new flows. The creation of new language infrastructures consumes resources and is very duplicative, as many of the functions of a language infrastructure are common to most or all implementations.
In addition, each different infrastructure generally maintains its own copy of the information about types and functions in its own way. Such multiple copies are frequently incompatible and it is generally difficult to maintain synchronization among such multiple copies.
Further, a conventional art language infrastructure generally provides limited flexibility in supporting types and functions. More particularly, it is rare for a conventional art language infrastructure to support user defined types and functions.
Conventional art language infrastructures are currently utilized in many tools. However, they are particularly poorly suited to the field of electronic system level (ESL) tools, as the common use of ESL tools is characterized by rapidly evolving flows.